INTERH AUON A L APPMCATION PUBLISH IM ( COOPERATION TREATY (PCT) 



(SI) International Patent Ctassilkatkw * : 
H04N 7/J O, 7/14 



ill) 

(43) msrmmmi 



Publication Date: 



WO 99/29108 

June ! 999 ( 10.06 .Wi 



(21) International Application 
(42) Imernatkmal Filing Date; 



4 December 1998 (041 2.98) 



(30) Wwriiy Data: 

60/067.452 
60/070, 106 
09/204,523 



4 December l»? (04.( 2.9?) 
.0 i>oember ;<,'V7 i"ii.;2.V") 
3- December 1 998 (03.! 2,9$) 



<"7U Applicant: Oil: S.ABOR.-X • OKIES IN COR PORATf.:D 
iOS/USl; 1209 Orange Street, Wilmington. DE 19801 
(US), 

(72) tHveetom PRAN5MAN, Andrew, 34 Howard Famt Road, 
Sharon, MA 02067 (US). CHlPALfCATO. Reott: 6 l-iskc 
Road, Lexington, MA 02420-2705 (US). 

(74) Agents? ANDERSON. Floyd, E. et al.; GTE Sen-ice. Corpora- 
tion, mo Hidden Ridge HQEQ30I 3 . Irving, TX 75038 {US). 



m\ Iks&gaato* States: C A. J?. European patent (AT B E. CH CY . 
DE, OK. fcS. Fi. I K. GB. 08. IK, IT, LU. MC, M„ FT. 

SB). 



Wirt hiterruVif»Uil search report 

8<-fi»-e thf expimsUm «,;/' ,-*c rune ww amending the 
claims and to he republished in iha even! of the receipt of 



{54} 'Oik: METHOD AND APPARATUS FOR KHAR VIDEO ON DEMAND 




(57) Abstract 

A roaster scheduler system a»x$ tr»elt>D<J automatically oper;,* snrf/c-r rowSirwte operation of a ptollty of relatively independent 
yst neluding manual y$te«ts> to func.t t $ NVOD s t *m to provide autom*; f_ it t \ x „ t - i >< r < 

a» NVOO system. The master scheduler system and method may aixo be appiied to automate manual processes of analog-based ami d=.e.*»l 
broadcast based service. The master scheduler (20) receives, presses, and disseminates NVOO sc.hedtne-^Ut-id information for end- to~«id 
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Technical Field 

This disclosure relates generally to the field of 
video distribution over a network, and in particular to a 
scheduling apparatus and method for providing near video 
on demand over a distribution network. 



When using a near-video-on-demand (KfVOD) system, a 
user such as a subscriber has the opportunity to purchase 
or rent videos such as movies, including recent hit 
movies, using a broadcast, technique known as staggered 
start. In a staggered start video distribution, a 
plurality of video signals, each of which corresponds to 
a single movie, is transmitted on multiple channels, with 
the beginning of each video signal starting at a 
different time- For movies with fixed play times, such 
different start times effectively stagger the movies by a. 
short amount. 

For example, the staggering time may be about 
fifteen minutes. Without staggering, a user has to wait 
for a movie to finish, which may he over two hours. 
Using staggering, a user waits, at most, only fifteen 
minutes; that .is, the stagger time. For typical movies 
lasting about two hours (120 minutes) , a staggered video 
distribution needs about 120 minutes / IS minutes of 
stagger time per channel = eight channels. Using 
multiplexing techniques, a plurality of staggered movies 
may be interleaved to transmit over the at least eight 
channels . 

NVOD systems typically use a back-end processing 
system which initiates and coordinates NVOD video 
scheduling, as well as performing remote schedule 
retrieval, schedule validation, schedule error handling, 
schedule distribution, video service content management, 
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event process modification, and dawnstxemn digital 
chancel allocation. Such operations are typically used 
for other digital broadband services, such as video on 
demand (V'ODi , home shopping, and video conferencing . 
5 Video distribution systems in the prior art 

implement VOD and NVOD, as well as staggered video 
distribution. For example, video distribution systems 
for storing, managing, and transmitting videos to a 
plurality of subscribers are described in commonly 

10 assigned U.S. Patent Mos . 5,168,35.3 to Walker et a : . ; 

5,311,423 to Clark; 5,3£3 f lil to Clark; and S, 583,93? to 
Ullrich et al . Typically, sued video distribution 
systems have a master scheduler connected to a video 
server, a billing computer, and optionally a downstream 

15 controller. The master scheduler sends a schedule in the 

form of, for example, a schedule file or database, to the 
video server, which, in turn responds to the schedule to 
d. 1 s t. r i be t e v i d eo s . 

Heretofore, such scheduling has been limited to 

:20 scheduling videos and transferring billing and customer 

requests to the video server. Other aspects of a video 
distribution system have generally not been automated, 
with various independent systems handling specific 
operations without coordination. 

25 A need exists for a video distribution system to 

provide operational support tor an HVOD system, for 
example, to track the bead-end configuration; to perform 
schedule revision, management and distribution; and to 
perform asset and content management. 

It is recognised herein that automating diverse 
operations for supporting and maintaining mOT) systems is 
aeeessary for t efferent jerai - £ suel y >" 
systems. A ir,a~t>-> soiebh: > t- m -tad method are 
.35 disclosed which automatically operate and/or coordinate 
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operation of a plurality of relatively independent 
systems, including manual systems, to function in unison 
as an MVOD system. The disclosed master scheduler system 
and method may also be applied- to automate manual 
5 processes of analog-based and digital broadcast -based 

service . 

The master scheduler receives, processes., and 
disseminates NVOD schedule-related information for end- 
to-end NVOD service; that is, sending video from a video 

2.0 server which provides video data to a head-end 

distribution system for delivery to and subsequent, 
viewing by a user.. The master scheduler also provides 
operational support for the WOD system, such as tracking 
the head-end configuration; performing schedule revision, 

15 management and distribution? and performing asset and 
content management , etc. 

In the prior art, scheduling information was 
typically keyed in manually. Video tapes were played 
according to the scheduling information. Since a video 

20 tape had to be played to determine the duration of the 

video program recorded on the video tape,, the duration of. 
the video program could not foe confirmed prior to playing 
of the video tape. Also, since each playing of an analog 
video tape tends to degrade the quality of the recorded 

25 video program., attempting to play the video tape in 

advance so as to determine the duration of the video 
program has the negative side effect of greatly 
accelerating tape degradation. 

Without being able to confirm the duration of the- 

30 video programs to be shown, the. prior art systems cannot 

validate the scheduling information, i.e. they cannot 
confirm that the video programs will, when played 
according to the scheduling information,, provide 
continuous video program material without temporal gaps 

35 and without, temporal overlap. 
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also, che prior art systems do not provide for 
propagation of information, such as billing information, 
program guide information, and factoid information 
{Specific factual information relating to a video 
5 program, such as the actors and actresses, the year in 

which the video program was created, any awards the video 
program may have won, etc,;, from an asset provider to 
various systems, such as a busiru j - > s em a"< 

electronic program guide system, and. a factoid provider 

10 system. 

Embodiments of the present invention are able to 
provide for reception, modification, validation, and 
propagation of schedni ing information and for propagation 
of information, such as billing information, program 

15 guide information, and factoid information to various 

systems. Embodiments of the invention also allow 
coordination between these various systems and 
modification of information in a manner that ensures 
consistency of the information among the various systems. 

20 HmJoodiments of the invention allow easier performance of 

administrative functions by avoiding the need for 
extensive manual entry of in tor mat ion and entry of 
information into multiple systems. 
Brief Description of the D rawings 

2S FIG. 1 illustrates one specific illustrative 

embodiment of an NVOD system using a master scheduler in 
accordance with our invention; 

FIG, 2 illustrates the disclosed master scheduler in 
greater detail; 

3D FIG. 3 illustrates a GOT screen for configuring; the 

hardware of the head -end; 

FIG. 4 illustrates a GUI screen for configuring the 
distribution status of the head -end r 

PIGS . 5A ; SB, SC., and 5D illustrate an information 
IS model for the master scheduler; 
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FIG . 6 illustrates sample code tor configuring the 
ittas t er sc hedu 3 . e r ; 

PIG. 7 illustrates an NVOD end-to-end channel map; 
FIG . S illustrates a data file structure; 
5 FIG. 9 illustrates an example of a schedule tor NVOD 

services; 

FIG. 10 illustrates a GUI screen for managing blocks 
of portions of schedules; 

FIG. 11 illustrates a GUI screen for managing 
10 programs in schedules; 

FIG. 12 illustrates a GUI screen for managing price 
changes of scheduled events; 

FIG . 13 illustrates a GUI screen for managing the 
status and distribution of. schedules ,- 
IS FIG. 14 illustrates a set of task states for 

distributing a channel line- up; 

FIG. 15 illustrates a set of task states for 
distributing a periodic schedule of programs and events; 

FIG, 16 illustrates a relational arrangement between 
20 scheduled programs, events* asset data, and asset tapes; 

FIG. 17 illustrates an asset metadata file 
structure; 

FIG. 18 illustrates a state diagram of the 
distribution of assets ; 
25 FIG. 19 illustrates a GUI screen for asset 

management ; 

FIG. 20 illustrates a GUI screen for accessing asset, 
metadata ; 

FIG. 21 illustrates data paths of content for 
JO content management in the disclosed master scheduler; 

FIG. 22 illustrates a GUI screen for importing and. 
loading files specifying schedules; 

FIG. 23 illustrates a GUI screen for content 
management of data providers ; 
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FIG, 24 illustrates a GUI screen for validating 
con t en t ma n a g emen t a c t ions t 

FIG- 25 illustrates a state diagram for loading and 
unloading content; 
5 FIG. 26 illustrates a timeline and flow diagram of" 

the perfomance of tasks ; 

FIG. 27 illustrates a state diagram of task 
progress ; 

FIG. 28 illustrates a state diagram of a task 
10 timeline; 

FIG. 2.9 illustrates a timeline- for task tracking? 
FIG. 30 illustrates a set of pull-down menus of a 
GUI screen of the master scheduler application; 

FIG. 31 illustrates a GUI: screen for purging 
IS records ; 

FIG- 32 illustrates a GUI screen for editing system 
parameters? 

FIG. 33 illustrates a GUI screen for editing event 
notif icat ions ; 

20 FIG. 34 illustrates a GUI screen for editing 

preferences and default settings; and 

FIG, 35 illustrates a GUI screen for managing tasks. 
Best Mode for Carrying Oat the Invention 

Referring in specific detail to the drawings, with 
25 common reference numbers identifying similar or identical 
elements, steps, and features, as shown in FIG. 1 .. the 
present disclosure describes an MVOD system 10 having a 
master scheduler 20 and method for scheduling and 
operating various functions of the IWOD system 10, For 
30 example , the master scheduler 20 receives, processes, and 

disseminates KVOD schedule- related information for end- 
to -end NVOD service; that is, for sending video from a 
video server which provides video data to a head-end 
distribution system for delivery to and subsequent 
35 viewing of a user. The master scheduler also provides 
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operational support: tor the NVOD system 10, such as 
tracking the head-end configuration; performing schedule 
revision, management: and distribution; and performing 
asset and content management , etc. 
5 As shown in FIG. 1, the master scheduler 20 is 

connected to a video server 11 which is, in turn, 
connected to a head-end 12 of the WJOD system ltd In a 
preferred embodiment, the video server 11 is a "HEWLETT- 
PACKARD" (HP) "MEDIASTREAM" server, a commercially 

10 available video server for iransfernng and processing 

video data to a plurality of subscribers 16, One 
embodiment of. video server 11 may include a server 
controller., a VMS/VTE interlace . a data source, an ATH 
switch, and a depot disk.. The VvlS/VTE interface allows 

15 interaction with a video management unit 90, for example, 

a Hewlett -Packard "Video Transfer Engine*' { VTEi video 
management Unit. The ATH switch controls transfer of 
data over a medium, for example, an asynchronous transfer 
mode (ATM) network. The master scheduler 20 may 

20 optionally be connected to a downstream controller 21 

which may be connected to or be included with the head- 
end 12, 

One embodiment of head-end 12 may comprise a video 
scream processing device, for example the ITEM. 1000, 

25 which is commercial !y available from General Instruments,. 

101 Tournament Drive, Horsham, m 19044. The video 
stream processing device receives video streams from the 
video server 11. for example, high-bandwidth MPEG -2 video 
streams over an OC-3 fiber optic medium, and generates 

20 multiple smaller streams suitable for quadrature 

amplitude modulation (QAM) transmission. For example, 
the OC-3 fiber optic medium may have an overall pay load 
capacity of approximately 120Mbps.. The video streams 
passed through the OC-3 fiber optic medium may each have 

3 5 a data rate of approximately 4.5Mbps, According to this 
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example, each of the multiple smaller QAM video streams 
may have an overall pay load capacity of approximately 
27Mbps for transmitting one or more of the 4,5Mbps video 
streams. The video stream processing device also 
5 encrypts video data from video server 11 and passes 

encrypted video data to the plurality of QAM~s . 

The head-end 12 may also comprise a plurality of. 
quadrature amplitude modulators (Qm~s) , a plurality of 
upconverters , and a summer (I). The QAM-s provide a 

10 signal modulated with the encrypted video data to the 

plurality of upconverters. The upconverters convert the 
frequency of the modulated signal and provide upconverted 
signals to a summer. The summer combines the upconverted 
signals from the upconverters for distribution. The 

15 head-end. 12* in turn, is functionally connected to a 

plurality of subscribers 36 having appropriate video 
viewing devices, such as set -top boxes {STBs) and 
descrambiers. In one embodiment of the invention, the 
video viewing devices may be coupled to the head-end 12 

20 using a hybrid fiber coax (HFC) medium. 

The master scheduler 20 may also connected to a 
communication device, such a telephone 52 and/or modem to 
other systems, and to a business support system (BSS) 88 
which may include a billing system 26, as in the systems 

25 described in the patents incorporated herein. As 

illustrated in FIG. 1... the master scheduler 20 may be 
configured with certain external components, for example 
those such as are present in the systems described in 
commonly assigned U.S. Patent Nos , 5,168,353 to Walker et 

10 al, ; 5,311,423 to Clark; 5,383,112 to Clark; and 

5, 583,937 to Ullrich et al. 

In addition, the NVOD system 10 may include a video 
management unit 90 connected to the video server 11, to 
allow an administrator to perform content management 

3 5 tasks, as described herein. 
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As shown in FIG. 2, the master scheduler 20 includes 
the following components, for performing specific 
functions: a head-end configuration manager 60, a 
schedule management syste.ro 62, a. schedule distributor 64, 
5 an asset management system 66, a video server content 

manager 68, a data management system 70, a task 
management system 72, a report generator 74, a security 
management system 76, an administrator interface 78.. an 
event notification generator 80, arid a memory such as a 

10 database 82. 

In addition to the components shown in FIG. 1, the 
master scheduler 20 is functionally connected to a 
schedule provider 84, a factoid provider system 8-6, and 
the business support system (ESS} 88. A provider 94 of 

15 asset data and metadata (i.e., data descriptive of the 
asset data ) is functionally connected to the master 
scheduler 20, and the video management unit 90, which .is 
a computer and/or processor having a graphic user 
interface (G0I5 92, is connected to the video server II. 

20 In particular, the video management unit 90. which may 

be a "VTE" management system available from "HEWLETT- 
PACKARD" , is used by an operator who receives information 
from the administrator interface 78 of the master 
scheduler, as shown, in FIGS. 1-2. The video management 

25 unit 90 may be remotely disposed relative to the master 

scheduler 20, and so both the video management unit 90 
and the administrator interface 78 may include components 
such as computer expansion cards to perform 
telecommunication protocols, such as TCP/IP, between the 

30 master scheduler 20 and the video server 11. 

The master scheduler 20 also generates reports 96 
and alerts 98, accesses various available assets and 
tapes 100, and performs operations procedures 102. 

The master scheduler 20 and the components thereof 

35 shown in FIG, 2 may be implemented in hardware and /or 
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software, for example, as a master scheduler application 
{MSA) , which may be a software program with source code 
written, for example, in C*+, or other appropriate 
programming languages. 

Using the data-base 82, the master scheduler 20 
stores and maintains head-end configuration data, which 
is used by the head-end configuration manager 60- The 
head-end configuration manager 60 is used to track the 

10 addition, deletion, modification, tracking, planning, 

viewing, and reporting of the head-end configuration 
information, including physical as well as logical 
channel parameters. 

FIG, 3 illustrates a GUI screen 104 for configuring 

15 the hardware of the head-end, which provides lists, 

scrollable lists, and descriptions of available items, 
such as channels and data providers, which may be 
activated on predetermined effective dates. In addition, 
the ports for such channels may be activated on 

20 predetermined effective dates. Such items and ports may 

have associated identification (ID) numbers, 

FIG. 4 illustrates a GUI screen 106 for configuring 
the distribution status of the head-end, in which lists, 
such as scrollable lists, of schedule line-ups and 

25 versions thereof may be displayed with the status of the 

distribution of each line-up. In addition, lists of data 
organisations such as the factoid provider 861 which 
provides factual information regarding video programs, 
and the BS3 88 may be displayed with the status of the 

30 distribution to or from the MVOD system 10, as well as 

confirmation dates and comments. 

The master scheduler 20 manages and controls the 
flow of information to and from the NVOD 10, As shown in 
FIGS- 5A. SB, 5C, and 5D, an information model 108 for 

3.5 the master scheduler 20 provides structural and 
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functional relationships between elements; and data. The 
information model 108 may be implemented using 
predetermined records or tables stored in memory, such as 
in the database 82. Alternatively, the information model 
5 108 may be implemented as objects and classes using 

obi ec t - orien ted programming . 

Each ox the elements 110-172 includes at least one 
field. Per example, each of the elements 110-172 
includes an associated ID, which may be alphanumeric. In 

10 addition, each item element 110 and each port element 112 

includes a description field and an effective date field. 

Also,- each item element 110 may be contained in the 
record or object of a port element 112. Each port 
element 112 includes a frequency ID number and an item ID 

15 number .. Each frecjuency- element 114 includes a frequency 
value,, and is associated with a respective port element 
112. Each digital stream element 116 includes a value 
field, a bit rate field, a virtual port ID (VPI) field, a 
port ID field, and a virtual circuit ID (VCI) field- In 

20 addition, each digital stream element 116 is associated 
with a respective port element 112. Also, each VCI 
element 118 is associated with a value field. 

Each channel element 120 includes an electronic 
programming guide (EPG) channel name field, a BGS service 

25 code field, and a set-top box (.STB) display channel 

field, as well as a digital stream ID field, a supplier 
number field, and a status ID field. In addition, each 
channel element 120 is associated with a respective 
digital stream element 116. Bach supplier element 12x1 

30 includes a supplier value field and a supplier name 

field, and is associated with a channel element 120. 
Each status element 124 includes a status field and is 
associated with a channel element 120, Each, channel 
history element 126 incltides a port indicator, a digital 

35 stream indicator, a bit rate field, a display channel 
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field, a channel name, a supplier nuwber, a status field, 
and an operative date . 

Each distribute line-up element 128 includes a 
distribution status field, a distribution date/ time, a 
distribution owner, a confirmation, status field, a 
confirmation date/time, a confirmation owner, and a 
remarks text message. Each line-up element 130 includes 
a vendor name field, a version number field, a start, 
date/time, an end date/time, and a status ID field. Each 
organization element 132 includes a name field, and each 
distribute schedule element 134 includes a distribution 
status indicator, a distribution date/time, a 
distribution owner indicator, a confirmation status 
field, a confirmation date /time, a confirmation or owner 
value and a remarks text message, 

Each program element 1.36 includes a title field, a 
short title field, a. description field, a language 
indicator, a start date/time, a duration value, a content 
indicator, a stereo status indicator for stereo audio 
transmissions, a Motion Picture Association or America 
tMF&A) rating indicator, an MPAA traits indicator such as 
indicating violent content, a type field, and a pay-per- 
view indicator, 

Each block element 138 includes a title, a start 
date/time, an end date/time, a stagger time duration, a 
price value,, and an indication that no channels are 
required for a given asset.. Each product element. 140 
includes a name, a valid start date/time, a valid end 
date/time, a price value, an indicator that programs are 
included with the product, and an indicator that an 
impulse signal is allowed. A product tile element 142 
includes a creation date/time, a vendor name, a start 
date/time, an end date/time, a schedule iSCHD) group 
name, a value indicating a number of records, and a 
status field. 
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Each module element 152 includes a name field, and 
each error log element 154 includes a task field, a 
description field, a date/time, an owner field., and a 
status field. Bach task type element 156 includes a task 
5 duration field and a time window field, Each 

notification type element: 158 includes a demo field, a 
level field and a notification field. Each cask element 
160 includes a details field, a recommended start, 
date/time field, a deadline field, a time status field, 

10 an actual start date/time, an actual duration field, and 

a progress status field to indicate how long into the 
duration of the task that the task is currently situated. 

Each registration element 162 includes a date/ time 
field and an owner field. Each notification element 164 

15 includes a details field and a date/time field. Each E- 

maii user element 166 includes a name field and an E-mail 
address field. Each metadata file field 168 includes a 
name field; a creation date/time field,, a number of 
records field, a received date/ time field, and a status 

20 field. Each asset metadata element 170 includes a source 

field,, a name field, a provider field, a live field 
indicating whether the asset is recorded from a live 
event, a satellite field, a transponder field, a 
transponder channel field, a polarisation field, an 

25 anticipated duration field, a pre-show field, a post-show 

field, a total time field, a shipped date/time field, a 
format field, a start date/time field, an end date/time 
field, a load date field, and a return date/time field. 

In addition, the asset metadata element 170 includes 

30 a barcode field, a duration field, an age field, a return 

rest.rict.ion field, an owner restriction field, arid a 
status field. Also, a default element 172 includes a 
name field, a value field, and a type field. 

Such elements 110-172 may be programmed, for 

3 5 example, using C4-* for configuring the master scheduler 
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20 to handle such data elements .110-172, and a sample of 
such code is shown in FIG. 6. 

FIG. 7 illustrates an NVOD end-to-end channel map 
generated by configuration of the head-end 12 as 
described above to have predetermined allocations of. 
analog frequencies. VCIs, VPIs, iters numbers, item ports, 
digital streams, bit rates, etc. 

In a memory, for example, the database 82, the 
waster scheduler 20 stores and maintains the head-end 
configuration, including both physical and logical 
channel line-up information la order to link scheduled 
content with the delivery channels of the NVOD system 10, 
as well as to validate and distribute the schedule. The 
head-end. configuration information is vised by various 
components of the master scheduler 20, such as the 
components 62, 64, 68, for providing the appropriate data 
far scheduling programming events and. for displaying 
program listings. 

The channel line-up information includes two types 
of information; physical information and logical 
information- The physical channel line-up information 
includes parameters which effect the properties of the 
channels of the cable provider . The logical channel 
line-up information includes the parameters which 
characterize the channels in the marketplace, such as 
channel identification and logos.. Such logical 
information may be modified without affecting the 
physical information, and so may be changed as necessary 

The master scheduler 20 may optionally perform the 
following channel Iine~up/conf iguration tasks: creation 
of new video channel entries,- deletion of video channel 
entries, loading of initial channel configurations, 
modification of channel configurations, version control 
of channel line-ups, and the viewing and reporting of 
channel line-ups. As described herein the head-end 
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configuration information may be stored using the data 
management system 70 , and may be viewed and modified 
using the administrator interface 78 with the GUT 92. In 
addition, the report generator 74 may be used to generate 
5 the reports S» o£ the information regarding the head- end 

configuration . 

The master scheduler 20 also validates the 
configuration of the head-end 12 and the channels by 
examining the correctness of the parameter values, 

10 checking for exclusiveness of predetermined parameters 

which require unique values, checking physical bound- 
related parameters such as the bandwidth of each and all 
of the channels., and checking other configurable 
predefined bounds such as STB: channel numbers . 

IS inconsistencies in the configurat on information mi> 

indicate incorrect scheduling. 

For example, the actual duration data from the video 
server 11 say be different than the duration indicated 
for the asset by the schedule provider 84 within a 

20 predetermined tolerance of duration discrepancy. The 

duration indicated for the asset, by the schedule provider 
84 is obtained from the asset provider, for example 
" AMEE IC.AST , " while the video server 11 determines the 
actual duration data itself. Accordingly, the duration 

25 of any particular event is to be identical in each of the 

files containing such records of the particular event. 

Other consistency checks include confirmation that 
the start and and times of a particular event have a 
duration equal to a predetermined duration of the 

30 particular event, in addition, content is not to be 

scheduled for play on the NVOD system 10 after a tape 
return date, and so such post-return scheduling indicates 
incorrect scheduling data received from the asset 
provider, for example * &MEE ICAST , * 
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NVOD channel set. aside as a test channel and so to be 
unused for broadcasting NVOD programs . The test channel 
may be used for validating that the correct content is 
5 loaded and may be played out of. the. video server 12. and 

decoded on an STB, for example.- subsequent, to the "loading 
of the content and before a scheduled viewing time. The 
test channel way also be used for monitoring video 
quality.. The head-end configuration thus has the test 

10 channel marked or otherwise indicated such that the test 

channel, and only the test channel, is used solely for 
testing purposes, and such that the test channel is not 
distributed or reported to the EPG and the schedule data 
provider. The test channel Stay also be encrypted. 

IS In order to program schedules and to set-up the 

head- end con figurations accordingly, the master scheduler 
20- generates multiple future versions of channel line- 
ups. The waster scheduler 20 also tracks past, current,, 
and future versions of the channel line-ups using, for 

20 example, the version field in the line-up elements 130, 

h new version may be marked as being a work-in-progress 
(W1P) before being marked as finalised, with only 
finalised channel line-ups being distributed. 
SCHEDULE M&H&CSKSKT 

25 The schedule provider 84 shown in FIG. 2 may obtain 

scheduling data from an asset provider, for example the 
'•AMERICAST* system, and, by virtue of being functional ly 
connected to the master scheduler 20, transmit this 
scheduling data to the master scheduler 20, For example, 

30 the schedule provider 84 may be connected to the 

scheduler management system 62 to provide a new and/or 
updated schedule in a data format representing content 
and /or event schedules to the schedule management system 
62 of the master scheduler 20. The data from the 

35 schedule provider 84 may include an electronic program 
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guide (BPG) data file having scheduling information, a 
product definition file which provides pricing 
information of available programs and events, and an 
asset metadata file which provides information on the 
5 content, and the tapes carrying the content. 

For example, the schedule file may be provided in an 
EPG data file having the format shown in FIG . 8. in which 
a header record is associated with at least one service 
(channel) record corresponding to a specific service or 
10 channel. Each service record is in turn associated with 

at least one program record having corresponding event 
records . 

The schedule management system 62 then converts the 
schedule from the original data format to a new data 

IS format which is used Internally by the master scheduler 

20, For example, the schedule format shown in FIG, 9 may 
be used as the new data format to have each program with 
corresponding events serially grouped for each 
service/channel, with multiple channels: having staggered 

20 start times for implementing the NVGD system 1.0. As 
shown in FIG. 9, each program may include a number of 
events, with at. least one being a main feature, and other 
events being previews and interstices; for example, with 
SWOD system announcements of start times of events and 

25 main features. 

The converted schedule is then processed by the 
schedule management system 62 with respect to the head- 
end configuration and previous schedule to validate chat 
the new and/or updated schedule is to be used by the 

3D master scheduler 20. For example, the validation process 
may compare the new and/or updated schedule with the 
previous schedule to ensure that there are no conflicts; 
that, is, no two events are scheduled at the same time or 
on the same channel. The schedule management system 62 

35 may be configured to give the new and /or updated schedule 
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precedence over the previous schedule; for example, to 
cancel a previously scheduled video program to broadcast 
a new video program. 

In addition, the integrity and correct format, or the 
5 received schedule in the first format may be checked by 

the schedule management system 62 prior to accepting the 
received schedule.. The consistency of the channel line- 
up of the received schedule is also checked to meet 
predetermined channel line-up specifications. Also, the 

10 assignment of events to channels according to the number 

of channels and an associated bandwidth may also foe 
checked, and the scheduling of events to have a proper 
time allotment may foe verified. 

in addition, the schedule management system 62 may 

15 determine whether sufficient time is available for a 

schedule to be processed, distributed, and implemented in 
the NVOD system 10. The schedule management system 62 
may also determine whether interstitial information such 
as event and program announcements as well as premieres 

20 may be placed between the events and programs. 

Upon completion of the validation process, the 
master scheduler 20 stores the new and /or updated 
schedule in the database 82 as a currently valid 
schedule. The master scheduler 20 then disseminates at 

25 least a portion of the currently valid schedule to 

external recipient systems, such as the video server 
the electronic program guide (EK5) system 87, the factoid 
provider system 06, and the BSS 88, which are 
functionally connected to, for example, the schedule 

30 distributor 64 of the master scheduler 20, as shown in 

FIG . 2, For example, the schedule may be sent in an FTP 
format via a socket protocol to a playlist application of 
the head-end 12 . 

The electronic program guide { E PCS ) system 8? 

35 provides a guide for viewers. Data provided to the EPG 
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system 87 by master scheduler 20 may be stored in an EPG 
data file having one or more service (channel) records, 
each having one or more program records,, with, each 
program record baring one or more event records. The: 
5 service records store information relating to a 

particular channel . The program records store 
information relating to a particular program, and the 
event records store information relating to events within 
a program, for example, portions to he shown as a preview 

10 of the program, 

The business support system (ESS) 88 includes a 
billing system 2S and is provided with information from 
master scheduler 20 that relates to business transactions 
involving the NVOD system. For example, the master 

10 scheduler 20 may pass information relating to the prices 

of scheduled events; to ESS 88. The price information is 
used by the billing system 26 to bill customers for the 
sc.he.dui ed even ts . 

In the distribution of tine current \\t « hi 

W the video server 11. may receive the downstream VCX and 

VPI information, while the factoid provider system 86 may 
receive, for example, only the titles of the videos 
available, and the BSS 88 may receive, for example, only 
the prices of the events. 

25 In an example, the factoid provider system 86 may 

optional iy be the commercially available system, and the 
BSS 83 may be the " IKTELICABLE S Y ST EM " (ITCi, which is 
Commercially available from "CABLED ATA B . 

PIG. 10 illustrates a OPT screen 1.74 for managing 

30 blocks of portions of schedules, in which a schedule 

specified by a name, time period, and/or version number 
is displayed for a plurality of channels labeled, for 
example, NVOD1 f KVOD2., and NVOD3 . The user may scroll 
through the plurality of channels and through the dates 
15 and months of a specified schedule. The status of the 
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schedule as being active or inactive may also be 
indicated. 

PIG . 11 illustrates a GUI screen 176' for managing 
programs within schedules, in which the stare and stop 
5 times may if modified f r sp* \L n grams for each 

channel,- The user may scroll through the plurality of 
channels and through Che daces and times of a specified 
schedule, Accordingly, schedules may be generated for 
selected time periods and selected services, Program- by- 

10 program and event - by •• event schedules may thus be 

manipulated. For example, program block schedules may be 
generated as an aggregated schedule of a specific program 
within one service/channel or across multiple services. 
The schedules may also be modified for selected 

15 ottr Homes, such at vers: or. • , n * and status; that tr 

active or WIFu In addition,, selected attributes of each 
program and event may be specified, such as: provider, 
source studio, MPS.P rating, content ratings, etc, The 
program block schedule allows a user to obtain an 

20 overview of the movies and programming events offered on. 

specific channels, with the duration of each event, for 
example , in terns of the number of days that the programs 
and events are scheduled to play, 

FIG , 12 illustrates a GUI screen 178 for managing 

25 price changes of scheduled events, in which the current 

price of a program or event may be changed and updated. 
The scheduled run-times of the program/ event as well as a 
scrollable list of a price history of the program/ event 
may be displayed. Accordingly,- flexible price editing of 

3 0 the schedule and specified programs / event s therein may be 

per formed . 

Using the GUI screen 178, an administrator may 
specify, through additional commands in pull-down menus, 
default prices to be applied to an entire schedule, as 
35 well as price changes for individual programs, for 
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programming blocks, and for different dates/times. The 
price changes may also toe effected for programs with 
specified traits, such as title, provider, studio, MPAA 
racings, etc. 

5 FIG . 13 illustrates a GUI screen. 180 for managing 

the status and distribution of schedules, which allows a 
user to scroll through and view the status and version 
numbers of schedules for a plurality of months. 

Through the GUI screen 180, the date of distribution 

10 and confirmation of such schedules to a plurality of 

organisations and entities may also be viewed, and 
remarks may be entered and. stored pertaining to such 
s e beau 1 e s % at us. 

The user may also distribute schedules by actuating 

IS a BEG IIS DISTRIBUTION icon, which causes the schedule 

distributor 64 to distribute all finalised schedules to 
available receiving entitles, such as the factoid 
provider system 86, the BSS 88, and the video server 11, 
for distributing the prepared and finalized schedules to 

20 the appropriate receiving entities at the appropriate 

time. Once the schedules are distributed, the XWOD 10 is 
prepared such that the subscribers 36 are able to browse, 
select, and purchase available programs and events 
through their STBs , 

25 FIG. 14 illustrates a set. of task states for 

distributing a channel line-up. After an initial W1P 
schedule is modified in step 182, and all. modifications 
are completed in step 184, the WT? schedule is finalised 
to be a current version, which is then distributed in 

30 step 186 by the schedule distributor 64, with the 

schedule entering a BEING DISTRIBUTED state. The master 
scheduler 20 then waits for confirmation, electronic or 
otherwise, from the distribution receivers. Upon 
receiving confirmation from each of the distribution 

35 receivers, the master scheduler 20 causes the schedule to 
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be in a fully confirmed state in step 1.88. In response 
to such a fully confirmed state, the schedule then enters 
an active state in step 190 t in which the finalised 
channel line-up becomes effective. 
S The master scheduler 20 then monitors the. daces and 

1 1 me s for each f .1 na 1 i zed s c hedul e . Wh en a s p e c i £ i c 
effective date/ time passes,, the master scheduler 2G 
causes the corresponding channel line-up tc enter a PAST 
state; that is, a state of no longer being effective in 

10 step 192 , 

As more up-to-date channel line-ups are generated to 
be subsequent versions, the subsequent versions are 
finalized and distributed to override the current- 
version. Accordingly., when a subsequent version is 

15 finalised in step 134. the current version of the channel. 

line-up is concurrently invalidated or overridden in step 
194, The finalised state of. the. current version is thus 
changed to be an invalid/overridden state. Similarly, as 
the subsequent version is distributed in step 136, the 

20 distribution status of the current version is changed in 
step 196 to be in an invalid/ over ridden state. Finally,- 
as the subsequent version is confirmed by all 
distribution receivers, the confirmation status of the 
current version is changed in step 198 to be in an 

25 invalid/ overridden state. 

FIG. 15 illustrates a set of task states for 
distributing a periodic schedule of programs and events; 
for example, daily, weekly, or monthly, etc. For 
example, for monthly schedules, after an initial monthly 

30 schedule of programs /events is received in step 200 from 

a schedule data provider 84, the schedule is received and 
loaded. The schedule is then validated and, if valid, 
accepted in step 202 to become an initial schedule which 
is in a WXP state. After any price changes are effected 

35 in step .204, the WIP schedule is modified until ail 



-22- 



WO WlSlfiN 



PCTAJ59*/OTn 



modifications are completed in Step 206. The WIP 
schedule is thus finalised to be a current version, which 
is then distributed by the schedule, distributor 64 in 
step 208, with the schedule being in a BEING DISTRIBUTED 
state. The master scheduler 20 then waits for 
confirmation from the distribution receivers. Upon 
receiving confirmation from each of the distribution 
receivers., the master scheduler 20 causes the schedule to 
be in a fully confirmed state in step 210. In response 
to such a fully confirmed state, the schedule then enters 
an active state in step 212, in which the finalised 
monthly schedule becomes effective. 

The master scheduler 20 then monitors the dates and 
times for each finalized schedule. When a specific 
effective date/time passes, the master scheduler 20 
causes the corresponding periodic schedule, such as daily 
or monthly, to enter a PAST state; that is, a state of no 
longer being effective in step 214. 

As subsequent periodic schedules are received and 
then validated in step 202.. a currently validated 
periodic schedule is overridden in step 216. Similarly, 
as a current WIP is modified, for example, to include, 
subsequent versions in step .218 and/or to include the 
price changes in step 204, the current WIP is overridden 
in step 220. Furthermore, as subsequent versions are 
finalized and distributed in step 205, the current 
finalised version of the monthly schedule is concurrently 
overridden in step 222. The finalised state of the 
current version is thus changed to be an 
invalid/overridden state. Similarly, as the subsequent 
version is distributed in step 208, the distribution 
status of the current, version is changed in step 224 to 
be in an invalid/overridden state. 

When the subsequent version of the monthly schedule 
is confirmed in step 210, the currently confirmed monthly 
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scb.edu I e is overridden in step. 226. Further, as the 
subsequent, version becomes the active monthly schedule in. 
step 212, the active status of the current version is 
changed in step 228 to be in an invalid /overridden state. 

The master scheduler 20 stores in the database 82 a. 
predetermined and reconi'igurahle value indicating a 
minimum time window fox determining a next schedule due 
date; that is, the date and/or time when a distribution 
is to commence. Such time windowing may be controlled by 
a schedule retrieval subsystem and/or the event 
notification generator SO of the master scheduler 20, 
such that the schedule is properly applied to components 
throughout the HVGD system 10, and that the schedule is 
properly validated in adequate time before the scheduled 
programs /events are to be broadcast by the HVOD system 
10. 

The master scheduler 20 may periodically interact 
with the schedule provider 84., which serves as a content 
provider, to receive an updated schedule, such as new 
schedules and schedule changes. For example, the master 
scheduler may poll the schedule provider 84 for the 
updated schedule. 

If a due date for distribution has passed without a 
distribution, for example, due to a lack in receiving an 
up-to-date schedule from the schedule provider 84, the 
schedule distributor 64 generates an alert which is sent 
to an administrator through the GUI 92 . In one 
configuration, the schedule distributor. 64 does not 
perform the distribution process unless the administrator 
manually initiates distribution, for example, relying on 
a previous monthly schedule of programs / events . In 
another configuration, the schedule distributor 64 may be 
set,- by default, to use the monthly schedule from the 
previous month. 
Asset. Management 



The asset management system 66 manages Che video 
assets, such as asset tapes, which are received from the 
assets and tapes data provider 100 <Fig> 2). It is to be 
understood that other forms of assets may be employed, 
including video disks, digital video disks and /or digital 
versatile disks (DVDs), film spools, etc. The asset 
management system 66 performs archival and retrieval 
functions to store and obtain video data in the database 
82. The asset management system €6 also tracks the 
status of. the video data; for example, when and how often 
a video asset is retrieved, 

FIG. 16 illustrates a. relational arrangement between 
scheduled programs, events, asset data, and asset tapes, 

An asset provider, such as N AM BR I CAST" or "DISNEY 
T VFKTUFE1 1 ^eiiodieaiiy sendn asset taper 2*0 frotr an 
asset storage location 232 to the head-end 12 and thence 
to the video server 11 of the HVOD system 10. 
Alternative lyt the asset tapes 230 may be provided 
directly to the video server II, The head-end 12 arid/or 
video server 11 subsequently provides the content from 
the asset tapes 23 0 to the subscribers 36, for example, 
using staggered broadcast times. 

However, prior to such distribution to the 
subscribers 36, the asset tapes 23 G are cataloged by the 
master scheduler 20. In addition, prior to return of the 
asset tapes 230 to the asset storage location 232, the 
cataloging of the asset tapes 2 30 by the master scheduler 
20 is updated, for example, to indicate return of the 
asset tapes 230 and/ or deletion of the entry for the 
returned asset tapes 230. Accordingly, asset management 
system 66 maintains asset data and metadata 94, which may 
be stored, tor example, in the database 82. 

As shown in FIG , 16, first asset metadata 234 may be 
maintained for a first event such as a .main event 23 6, 
and second asset metadata 23 8 may be maintained for a 
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second event, which may be a plurality of identical 
events 240, 242, 

FIG - 17 illustrates an asset metadata file structure 
for the asset metadata 234, 23B of FIG. 16, with a header 
5 record being associated with at least one asset metadata 

record. Each asset metadata record is in turn associated 
with at least one asset event record. The asset event 
records may include indicators specifying that the event 
corresponds to a main event- 

ICS FIG. 18 illustrates a state diagram of the 

distribution of assets. When an asset tape arrives at 
the head-end 12, if no metadata associated with the asset 
tape is in a database of asset -metadata, for example, 
stored in the database 82 ? the asset tape is received in 

15 step 244 to have such asset metadata generated and /or 
entered into the database. The asset tape is then 
checked in through the asset management system 86; that 
is, the asset tape is indicated in step 246 to be 
available to the video server 1.1 for distribution to 

20 subscribers 36. 

Alternatively, if the asset tape arrives and 
associated metadata is present in the database; for 
example, if the asset tape had been previously used by 
the SVOD system 10, then the asset tape is directly 

25 checked in through the asset management system 66 in step 

246. 

Once the asset tape is checked in, the asset tape 
may he checked out in step 248, for example, to load the 
asset cape onto or into the video server 11 for 
30 distribution to subscribers 36 according to the finalized 

schedules . 

During steps 244-246, it may be determined that a 
specific asset tape is instead to be returned to the 
asset storage location 2 32; for example, if there xs no 
3 5 need for she specific asset tape in the foreseeable 
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schedules of the NVOD system 10, Accordingly, the asset, 
tape is received by the asset management, system 66 in 
step 250 in order to have the asset metadata of the asset 
tape updated to indicate that the asset tape is being 
S returned. The asset tape is then shipped out to the 

asset, storage location 232 in step 252. 

During steps 244-248, the integrity of the asset, 
taps may be checked prior to processing. The asset tape 
may foe determined no be corrupted; thai:, is, physically 

10 damaged, inf ermationaily damaged including magnetically 

erased, or unidentifiable in the course of attempting to 
generate or process the metadata thereof.. If the asset 
tape is corrupted, then the asset tape is recorded in 
memory in step 254 as having a corrupted state, and then 

15 the asset tape is returned to the asset storage location 

after steps 250-252 are performed to indicate the return 
of the asset tape and to ship out the asset tape. 

Accordingly, an asset may be tracked, and managed 
over the entire life cycle of the asset in relation to 

\20: : the master scheduler 20 and the NVOD system 1.0, The 

assets and the contents thereof may thus be cataloged and 
tracked as to the states of the assets. Such asset 
metadata by cataloging and tracking may be reported using 
the report generator 74 to generate reports 96 on the use 

25 of assets and the functioning of the NVOD system 10. 

FIG,. 19 illustrates, a. GUI screen for asset 
management, in which, the asset data and metadata may be 
viewed and edited. For example, a plurality of assets, 
such as asset tapes, may be viewed with a listing of 

3 0 corresponding barcodes, tape names, locations, status as 

received and/or corrupt, and the current status such as 
being scheduled to be loaded. Individual tape details 
may also be viewed to list, the barcode, tape name, and 
location of a selected tape. Comments may also be 
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entered, .stored, and subsequently viewed concerning a 
specific tape. 

A plurality of icons may foe provided to allow a user 
to receive a tape,, check the tape in, check the tape out.., 
5 return a tape,, mark that the tape was corrupt, and other 

functions for reviewing and processing the asset 
metadata . 

As shown in FIG, IS, the user way select and browse 
through a plural i cy of. records in a plurality of modes 

10 such as view mode and edit mode. Other functions may 

also be supported, such as printing the records, and 
saving and/or deleting records. 

FIG. 20 illustrates a GUI screen tor accessing asset 
itisuadata, in which greater details may be retrieved from 

IS memory and reviewed. For example, the name of the asset 

and the source and provider IDs may be indicated.. The 
shipping , loading, and return dates and times may be 
indicated, as well as the data sise of the asset 
metadata, In addition, the user may input and thence 

SO. retrieve additional information such as return 

instructions for properly returning the asset tape, and 
other instructions such as instructions common to 
different tapes, for example, to specify that a set of 
tapes are to be returned together . 

25 The asset management system 6 6 processes the asset: 

metadata to check such information against: the schedule 
information. For example, an asset may be received which 
is scheduled for broadcast, so the processing of the 
asset and the asset data /metadata thereof may be given 

10 priority in processing. In addition, the duration of an 

actual asset may be compared to the scheduled duration of 
the asset in the asset metadata file. For example, 
actual asset lay r» loaded bite v 'idec server 11 By 
measuring the amount of storage space needed on video 

IS server ii to store the actual asset., given a known rate 
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at which the data comprising the asset will be played, 
the duration of the actual asset can be determined. 
Significant, discrepancies may cause the asset management 
system 66 to generate an alert and/or to reconcile the 
S discrepancy, for example, by determining if the. asset 
metadata of a specific asset tape is in error. The 
return date of the asset may also be checked against the 
schedule, for example, to ensure chat the asset is 
returned after any scheduled broadcast., and not before a 

10 broadcast . 

By utilising bareoding methods with asset tapes, the 
physical tape entity may be correlated to the associated 
asset data/metadata. In addition, a location code may be 
assigned to the physical asset tape,, with a location 

IS label having the location code emplaced on the physical 
asset tape. The location code may indicate a designated 
location for storing the asset tape in the 3SJVGD system 10 
prior to return to the asset storage location 232. 

The asset management system 66 may also generate 

20 alerts through, for example, the event notification 

generator SO to provide warning messages in the event 
that, a user is attempting to check out an asset taps 
which is currently loaded in the video server II and/or 
which is scheduled to be loaded on the video server 11, 

25 unless the asset metadata of the specific asset tape 

indicates that the asset tape is in a corrupted state, 
Video Server Cont e r;t ...Man a_g emen t . 

The video server content manager 68 communicates 
with the video server 11 to inquire about content -related 

30 information. For example, the video server content 

manager 68 determines when and where to load /unload an 
item of content, such as a video asset. 'The video server 
content manager 68 also performs an operations procedure 
102 to allow administrators to monitor and control the 
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loading and unloading of content, and validates the 
content loading and unloading of the content. 

FIG. 21. illustrates data paths of content for 
content management in the disclosed master scheduler 20, 
5 The video server content manager 68 receives information 

from the video management unit. 90, .such as an HP VTE 
terminal, as well as from the schedule provider 84. The 
video management unit 90 sends HP VTE information,, such 
as content information and data provider disk space 

10 utilisation, to the video server content manager 68. The 

content information may include content, title, content 
size, bit. rate, and duration of the content. 

The schedule provider 84 sends SPG schedule fields 
87 such as service records, program records, and event. 

15 records in a format such as shown: in FIG. 8 . In 
particular, the service records include a channel 
designation, the start and end dates/ times ( and the 
number of programs. The schedule provider 84 may also 
send content information, such as asset data and metadata 

20 from the "CAPS" system of "AMERICAS?, * to the schedule 
management system iSBS) 62 of the master scheduler 20, 
and thence to the video server content manager 68. 

The asset metadata 94 may fee provided from the asset, 
management system 66, including an asset name, bit rate, 

25 size, duration, start date* end date, load date, .return 
date, and assigned barcode. 

Upon receiving such content information, the video 
server content manager 68 generates error logs, tasks,, 
and reports, which may foe processed through the event 

30 notification generator 80, the task management system 72, 

and the report generator 74 {Fig, 2),, respectively. 

FIG. 22 illustrates a GUI screen 256 for importing 
and loading files specifying schedules through the video 
server content manager 68. From the screen 256, the 

35 administrator may load content to the video server 11 
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imported/downloaded content such as assets and tapes 100 
from an asset provider, such as "AMERICAS?, * as well as 
schedules, "CAPS- SMS* data, and asset metadata 94, In. 
5 addition, the administrator may also load content 

presently stored in the database 82 of the master 
scheduler 20 as local files to the video server 11. 

FIG. 23 illustrates a GUI screen 258 for content 
management of che video server's data sources, in which 

10 each daca provider is identified by name or designation, 

by a respective total capacity, and by the remaining 
capacity for providing content. The status of each data 
provider as being available or dowrt (unavailable) is also 
provided, and the last update of the status and capacity 

15 of each data provider may also be listed. 

FIG . 24. illustrates a GUI screen 260 for validating 
content management actions. For example, each available 
asset may be listed by title and/or asset ID number, The 
scheduled loading date may be displayed, as well as the 

20 status of the loading to the. video server 11. The status 
of a task may also be displayed, to indicate that a task 
is loaded or unloaded. If a task is loaded, the task is 
ready to be performed, i.e. to load the video server 11 
with the corresponding asset. In addition, for 

25 validating a specific asset through the screen 260, the 
status of an. asset may be checked by actuating a CHECK 
STATUS icon. The validation of the specific asset may 
also be performed by actuating the PLAY ON TEST CHANNEL 
icon to utilize the test channel to view the asset for 

30 verifying the integrity of the asset prior to 

distribution to subscribers 36, 

FIG. 25 illustrates a state diagram for loading and 
unloading content. Once the event data, asset data, and 
asset taps are received as content, the content is 

35 scheduled to be loaded according to the validated 
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schedule determined by the schedule snanagsjnenc system 62. 
described above. At appropriate loading times., the 
concent is loaded into the video server II. This loading 
step may be performed by transferring data to the video 
server, for example electronically > or by loading media , 
such as video tapes. The assets may span multiple tapes, 
and so the loading step may require multiple steps to 
fully load some video content such as movies into the 
video server 11 . 

The content is then in a loaded state in the video 
server 11, From the loaded state, any specific item of 
content may be in an active state or be in an inactive 
state; for example, the item of content may be loaded in 
advance of a scheduled start time, and so the item of 
content waits in. an inactive state until used or 
unloaded, for example, in the event of a schedule change. 

Once the item of content is active according to the 
schedule, the item of content may then be played by the 
video server 11; that: is, the item of content is sent to 
the subscribers 36. Since the m&D. system 10 staggers 
content by predetermined time intervals, portions of an 
item of content may be active, and not playing, while 
other portions are active and playing. However, once an 
item of content Is no longer playing, the item of content 
jnay enter the active state or the inactive state. 

According to the current schedule, either the item 
of content is to become active subsequently,- or the item 
of content is scheduled to be unloaded from the video 
server 11. As indicated in FIG. 25, no inactive content 
is playable until the status of the content is changed to 
the active state. 

In addition, an active item of content may be 
scheduled to be unloaded, according to the current 
schedule, immediately after play, and so the item of 
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content need not enter an inactive state to foe scheduled 
to be unloaded . 

Once, scheduled for unloading, the content is 
unloaded from the video server II, which may require 
5 multiple passes to remove and/or erase predetermined 

amounts of the content. The content is then in an 
unloaded state, and the content is subsequently checked 
out as being unavailable by the asset management system 
66. 

XO The video server content, manager 66 of the disclosed 

roaster scheduler 20 uses an intelligent processing method 
to determine when and where to load/unload content for 
each scheduled event- The video server eon tent manager 
68 operates using factors such as the configuration of 

IS video server data providers, the remaining space of the 

data providers., a load balance among the data providers, 
the content currently loaded into the video server 11, 
the scheduled working days, hours, and holidays of manual 
technicians such as the administrator, who would 

20 physically load tapes if necessary, an estimated time to 
load/ unload content, the time to verify the content by 
looking at all or part of it, the content currently 
queued to be loaded /unloaded, a required quality 
assurance (QR) time, etc. 

25 For example / the intelligent processing method of. 

the video server content manager 68 may have general 
goals to maximise performance, such as functions to 
minimize the number of. uses of any single data provider , 
in order to minimize any loss of programs and revenue if 

30 a data provider becomes available, including system 

maintenance or if the data provider goes down. Another 
goal may include minimizing the number of. simultaneous 
uses of or demands upon any single data provider, and 
also adjusting load balances among a plurality of data 

15 providers . Pass- through procedures may be performed, 
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such as the determination of main events loaded from each 
data providers, and then, for each unique main event , the 
current and future schedules are scanned to determine the 
current uses and she number of simultaneous uses of the 
5 data providers. In addition,, for each data provider, the 

total current and future uses of main events are 
determined. For each new portion of a main event, a data 
provider is determined which has a minimum number of 
uses, such that if the determined data provider has 

10 enough memory space and stream slots, then the main event 

is placed from she data provider . 

As the video server content manager 68 interacts 
with the video server 11, validation procedures are also 
performed to determine if appropriate assets are loaded; 
IS otherwise, an alert is generated upon the discovery that. 

an incorrect asset is loaded/unloaded. In addition, the 
video server content manager 68 also polls the video 
server II at regular intervals to verify that a load 
content instruction was performed properly; otherwise, an 
:M alert is generated. 
Data Management 

The data management system 70 maintains the database 
82 for storing information about the assets from content 
providers, as well as network configurations used to 

25 transport video data, such as MPEG- 2 video bit streams. 

The data management system 7 0 also stores the current 
valid schedule for delivering NVGP events to the 
subscribers 36. Other persistent data used by the master 
scheduler 20, such as the operating parameters and user 

30 login data such as passwords, as well as an operating 

system and application programs executed by the master 
scheduler 20, are stored in the database 82 and 
maintained by the data management system 70 . 

The database 82 may be a commercially available 

35 database 83 from " ORACLE " such as the "ORACLE" 1 A. X 
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database, and so the data management system 70 may 
include an " ORACLE" interface using; for example.. 
"SQL* SET*. 
Tag: Mangy s nj 

5 The task management system 72 coordinates and causes 

the execution of tasks and sub-tasks performed by the 
master scheduler 20, and also tracks the execution and 
status of such tasks and sub- tasks, in order to complete 
all tasks in an orderly and tamely manner. 

10 FIG . 26 illustrates a timeline and flow diagram o£ 

the performance of tasks and task dependencies. The 
caster scheduler 20, through the MSA, updates the chancel 
line-up in step 262, and the MVOD system 10, such as a 
"GTE " NVOD apparatus, sends the channel line-up to the 

|.S schedule provider 84 in step. 264, which develops a 

program schedule in step 266 for a specific period 
beginning at time X ami ending at time Y . The schedule 
provider B4 creates schedule tiles in step 268 for the 
NVOD system 10, and. the MSA receives the schedule files 

20 therefrom in step 270, 

The MSA. then validates, stores, and updates tne 
schedule in step 272 { and the MSA then creates in step 
274 a task schedule and milestones; that is, indicator 
events, times, and tasks which are used to gauge the 

25 operation of the master scheduler 20. The MSA proceeds 

to generate a piayiist and send the pi ay list to the video 
server 11 in step 276; distributes the schedule 
information to the factoid provider system 86, such as 
"TVBATA" , in. step 278; sends the schedule information to 

30 the ESS 88, such as the "CABLEDATA INTEL, I CABLE SYSTEM 1 ' 

(I.TCi in step 280 ; performs automated content management 
tasks in step 2 82, as described, above; and generates 
periodic tape loading instructions and alerts in step 
284. The seeps 276-284 are commenced at substantially 

3 5 the same time. 
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After step 2781 the video server 11 receives the 
play list from, the MSA and streams out content in step 286 
from start time. X to end time Y to preform the NVOD 
services over the plurality of channels according to the 
5 schedules and pi ay list from the MSA, 

After step 278, the factoid provider system 86 
augments program information with the distributed 
schedule information., and sends schedule information to 
other facilities, such as " STARS IGHT" . In addition, each 
10 of the NV'OD system 10, the factoid provider system 86. 

and the other facilities perform quality assurance (QA) 
procedures for ensuring, for example, that the schedule 
information is consistent and in the correct format. 

After step 28C, the BSS 88, such as the " CAB LED AT A 
15 XTC" system, performs a QA procedure on the received 

schedule information, and sends the schedule information 
to the ITC interface of the WQD 10, which may be 
functionally connected to the schedule distributor 64 of 
the master scheduler 20, The WSOD 10, In turn, sends the 
20 schedule information to the head-end (HE) 12. 

For any task schedule generated by the MBA. in step 
274, the seep 282 of automated content management is 
performed over a relatively long duration, and also into 

25 in order for content to be processed and managed to send 

content to the video server 11 for operation during the 
scheduled time window. 

In addition, step 288 is performed over a relatively 
long duration such that the acquisition of assets and the 

30 generation and transmission of tapes by the schedule 

provider 84 begins when the master scheduler 20 sends the 
channel line-up in step 264. The acquisition and 
transmission of tapes may also extend into the scheduled 
time window to provide the video server 11 with the 

3 5 s c h e du 1 ed assets and content. 
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Because tape loading instructions are generated in 
seep 284 , the master scheduler 20 instructs the video 
server II and/or the video server content manager 68 in 
step 2.90 to load and/or unload specific tapes, for 
5 example, to prepare for upcoming scheduled events. A QA 

procedure may then foe performed in step 292 to ensure 
that the proper tapes have, been loaded and/ or unloaded, 
and especially in sufficient time before a scheduled 
event to remedy any loading /unloading errors. 

10 Tha tape loading instructions from step 284 may also 

instruct the video server content manager 68 to check-out 
tapes in step 294, for example, if a schedule is modified 
co cause some tapes to be unnecessary and so returned to 
the asset storage location 232. 

1.5 During the schedule window, the master scheduler 20 

may continue in step 296 to instruct the video server 11 
and/ or the video server content manager 68 in step 29 Q to 
load and/or unload specific tapes, for example, to 
prepare for upcoming scheduled events during the schedule 

20 window, and to unload used tapes after the corresponding 
events have occurred. 

In step 288, assets are repeatedly sent, and so in 
steps 298, the assets are repeatedly received at the NVOD 
10 from the asset storage location 232, and the master 

25 scheduler 20 in turn archives the assets, for example, by 
checking tapes in ; and holding onto the tapes until the 
assets thereupon are loaded onto the video server 11. 

FIG. 27 illustrates a state diagram of task 
progress. After a task is created, the corresponding 

30 operation of the task, begins and the task enters a WIP 

state. The operation .is then in progress until 
completed,- when the task enters a completed state, 
FIG. 28 illustrates a state diagram of a task 
timeline, After a task is scheduled for a specific early 

35 start date/ time, the task enters a scheduled state. For 
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example , the tasks may involve loading a specific tape 
for a specific scheduled event. As the task is 
performed, as shown in FIG- 27, the task management 
system 72 tracks the start dates and times as time 
S passes . If the scheduled start date/ time occurs and the 

task has been completed., the task enters a completed 
state. 

Otherwise, if the start date/time passes, the task 
enters an urgent state. The task management system 72 

10 then determines if the task has been completed and/ or is 

a WIP. If completed, the task enters the completed 
state. If the task is not completed and is not a WIP, an 
alert is generated and sent to the event notification 
generator SO, and the task is stopped. The task then 

15 enters a stopped state, in which the task is too late to 
be completed, 

FIG. 29 illustrates a timeline for cask tracking, in 
which the early start date, the urgent start date, the 
latest start date, and a deadline are set, and are 

20 maintained and stored in memory ., such as the database 82. 
The master schedule 20 includes a clock device for 
monitoring and updating a stored value of the current 
date and time. At least the task management system 76 
monitors the current date and time to determine whether 

.25 such start dates and deadlines have occurred, and so to 
generate alerts * 

During the alerting period between the urgent start 
date and the latest start date, alerts are generated to 
indicate that a task is to be initiated before the latest 

30 start date in .order to allow the task to have sufficient 

time to be completed before the deadline. The latest 
start date is determined to provide at least a minimum 
time for the task duration, as well as optionally some 
tolerance time. The alerting period may be any arbitrary 

35 time period predetermined and set by an administrator. 
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Automated tasks are automatically performed, unless 
overridden by an administrator . Manual tasks are 
performed by an operator who is alerted by the event 
notification generator 80 in response to alert signals 
5 generated by the task management system 72 . 

In cresting task instructions, as in step 274 of 
FIG. 26, the task management system 72 generates 
appropriate signals to the report generator 74 to have 
the task schedule and instructions reported weekly for 

10 work planning purposes, and reported daily tor causing 

the performance of tasks for any given day. The task, 
instructions are also used to track the progress of tasks 
according to the scheduled start and completion times of 
tasks, the actual start and completion times, any errors 

IS encountered,, and the results of such tasks, and the task 

management system 72 generates corresponding; task 
tracking data reflecting such task progress. The task 
management, system ?2 may forward the task tracking data 
to the report generator 74 to generate task progress 

20 reports. 

Content management tasks see generated by the task 
management system 72 using parameters from the video 
server content manager 68. For example, the content 
management ta.sl art step-bj star insti icti >ns for 

25 instructing the video server 11 to load, unload, and 

relocate assets to and from tapes. 

In generating such content management tasks, the 
a mat sgeit t > tern 72 provi< r torre t 

procedures, commands, and parameters to indicate which 

30 tapes to obtain, where each tape is located, which tapes 

to load for an upcoming schedule, which content to unload 
from the video server 11, and how to load and unload 
assets from designated providers and destinations, 
respectively. The task management system 73 rosy 

35 interrogate or poll the video server 11 at regular 
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intervals, such as daily, to ensure that the tasks are 
performed properly and routinely. 

The task management system 70 may also generate and. 
manage tasks for asset, management in conjunction with the 
S as et management i te! 6< for sample o » m t 

delivery and shipping of tapes from the asset- storage 
location 232, including logging shipping slips as well as: 
affidavits of delivery and return of tapes to and from 
the WOD 1 0 . 

10 Repor t Product ion 

The report generator 74 allows users, such as system 
administrators, to generate a variety of pre-defined 
reports 96. The report generator 74 may he hardware 
and/ or software commercially available from "ORACLE", and 

IS is functionally connected to at least one output device, 

such as a printer,, a display, a disk storage system, or a 
network: on-line connection, to generate corresponding 
reports therefrom. The output device may he included in 
the master scheduler 20, or alternatively may be external 

20 to but functionally connected to the master scheduler 20. 

For example,; the reports 36 may foe visually 
displayed through the GUI 92 by sending the reports 96 to 
the administrator interface 78. A user may then print 
the form from the screen by a screen capture procedure, 

25 which may involve blocking off a selected portion of the 

report, on the screen to be printed,. 

The report generator 74 may prepare and issue the 
following types of reports: channel conf iguration/line- 
up report, asset and tape catalog report, server content 

30 report, task management report, event schedule, and 

trouble/ error report. 

The channel conf iguration/ line-up report is 
generated in response to receiving a date to determine 
when the channels are in effect. The channels may be 

35 presented in tabular format, such as shown in F-IO, 7, 
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which lists the physical as well as logical configuration 
information for the mOD channels originating from the 
video server 11 and ending at the STB of the subscribers 
36. Reports of channel line-up changes, such as changes 
5 to the latest version of the line-up, may also he 

generated . 

The asset and tape catalog report provides an 
inventory of all tapes and. assets which are currently in 
the possession of the NVOD 10. The report generator 74 

10 may include filtering and sorting functions to obtain, 

for example, lists of tapes to be returned, or lists of 
assets currently loaded in the video server 11. 

The server content report supsari«es the contents 
and. assets on the video server 11 at any specified 

15 moment, and includes information such as metadata of the 
loaded content, location of the content, and whether the 
content is currently in use; that is, playing and being 
streamed out to subscribers 36. The server content 
report maybe be generated to foe arranged according to 

20 content title, content status, and/or content location. 

The task management report may foe; generated on a 
daily or weekly basis to list the tasks and instructions 
to be performed by the W&& 10 and by the administrators 
using the master scheduler 20. The milestones and 

25 progress charts may foe listed indicating milestones 

reached and/or progress for a specified day or week. For 
manual loading, unloading, and relocation of content, 
administrators may use a content management report 
regarding content management which is generated to 

30 provide detailed content management procedures which 

administrators are to follow, for example, through 
commands input via the video management unit 90 and /or 
the GUI 92. The content management report may foe 
generated with or as a portion of the task management 

35 report. 
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The event schedule may be generated in a format such 
as shown in FIG., 9, The trouble/error report way list 
errors encountered and generated alerts in an error log, 
for example, in chronological order, 
5 - iar rty^IMe & I i.i lf Qt 

The security management system 76 maintains security 
protocols to ensure that only legitimate users may gain 
access to the operations of the master scheduler 20. The 
security management system 7 6 also ensures that only 

10 authorised operations according to predetermined 

privileges may be performed via the master scheduler 20. 

A user database is maintained,, for example, in the 
database 82, which lists user names and passwords of 
authorised users such as administrators of the master 

15 scheduler 20. Login and confirmation of passwords as 

well as re-login procedures may be performed. The re- 
login procedures may foe performed if the master scheduler 
20 times out; that is, if the master scheduler 20 is 
relatively inactive for a predetermined time period. 

20 In addition to user management, access control, is 

maintained with hierarchies of users having associated 
privileges, such as read-write privileges as opposed to 
read-only privileges. For example, read-write privileges 
may be assigned only to local users such as 

25 administrators, while remote users such a.s tape receiving 

personnel may be granted only read-only privileges. 

Four security hierarchies may be provided; labeled 
MSA_yIEW (viewer), MSAJ4KTG (marketer), HS.A„0PBR 
{operator) , AND HSA-ADKN (administrator) , A user with 

30 KBAJ/XSK access has rights to view schedule-related data 
reports, prices, programs, schedule dates, pending tasks ; 
etc, h user with MSA..HKTG access has the rights of an 
KSA_VIEW user as well as rights to edit /save prices and 
to finalize schedules, A user with KSAJ3PER access has 

35 the rights of an. MSA„MKTG user as well as rights to 
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import and load files, to perform schedule processing and 
distribution- to perform diagnostics, and to manage 
assets and content. A user with MSA„ADMN access has the 
rights of an MSA_jQP£# user as well as rights tic configure 
5 the head -end 12, to configure assets, and to perform 

securing management., as well as to access all functions 
of the master scheduler 20. 

- -> .'-".a. tor Interface Fac.i I i r. las 

The administrator interface ?S allows an 

10 administrator to view schedules, to make price changes 
for the use of the NVGD system 10, to perform content 
management using the video server content management 
system 68, and to generate reports using the report 
generator 74 . In addition, administrators may perform a 

1.5 predetermined shutdown procedure through the. 

administrator interface: 78 for properly shutting down the 
master scheduler 20 and /or the NVOD system 10, The 
administrator may also use the administrator interface 78 
to export records and data from the database 82 and 

20 perform other system management tasks, as described 
herein. 

The administrator interface 78 may include the 
graphic user interface {GUI) .52, such as a GUI interface 
based on "WINDOWS" such as "WINDOWS NT" , available from 

25 MICROSOFT CORPORATION . Accordingly, administrators are 

provided an easy-to-use, interactive, and point -and-click 
facility to access the functions of the master scheduler 
20 and the NVOO 10- 

FIG . 30 illustrates a set of pull-down menus of a 

30 GUI screen .300 of the master scheduler application, which 

allows an administrator, for example, to import/ load 
content to the video server 11; to set and edit system 
parameters, preferences, and notifications,, such as 
notifications generated by the event notification 

35 generator 80; to manage schedules, content, and tasks; to 
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configure Che head -end 12; and to generate and print 
reports /logs 96 through the report generator 74. Such 
reports 96 may include indications of notifications, 
error logs, channel lineup, server content, tasks, 
5 s c hedu 1 e s , and assets . 

As shown in FIGS . 30-35, the various display screens 
may be generated through the GDI 92 of the video 
management unit 90, which may be a terminal 1 or 
workstation. Though point -and-click interaction, an 

10 administrator has access to the functionality of the 

master scheduler 20 to administer the NVOD 10. 

Alternatively 4 the various display screens may be 
text and/or non-GUI oriented screen interfaces, such as 
choices displayed on a screen which may be selected by 

15 tabbing using a TAB key, or otherwise relying on specific 
keyboard commands such as hotkeys and key combinations, 

FIG. 31 illustrates a GUI screen 302 for purging 
records, which may be an option available to the 
administrator through the ADMINISTER command on screen 

20 300 of FIG, 30. Through the GUI screen 302, an 

administrator is able to select a range of dates for 
marking any programs, events, and tasks in such a range 
for deletion. The administrator may then delete the 
records by actuating the DELETE icon., and so to purge 

25 outdated records to clear memory in the video server 11 
as well as to improve the efficiency of the master 
scheduler 20 to process all of the available records, 
since outdated records may be unnecessarily processed 
with up-to-date records. 

30 FIG. 32 illustrates a GUI screen 304 for editing 

system parameters, such as the default price tor pay-per- 
view events, a minimum distribution time of the finalised 
schedules to the factoid provider 86 and the BSS 88, a 
minimum loading time of content to the video server 11 in 

35 advance of a scheduled time for the content, and hardware 
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configuration parameters such as the- maximum number of 
Vtts, the maximum number of. STB display channels, and the 
range of channel frequencies such as the maximum and 
minimum channel frequencies allotted to the NVOD 
5 channels, Such parameters may foe scrollable and 

selectable through the "WINDOWS" -based GUI screen 304 
shown in FIG > 32 - 

FIG. 33 illustrates a GUI screen 306 for editing 
event notifications, through which the administrator may 

10 enter and alter the status and conditions by which the 

event notification generator 80 responds to alert 
conditions. Through the GUT screen 306, the type of 
notification may be specified as normal or alert. A 
normal notification may foe a pop-up dialog box or text on 

15 the screen which is generated upon occurrence of the 

corresponding condition, such as a change in a schedule, 
which may be of interest to the administrator, 

Alert conditions may include the occurrence of an 
abnormal condition -which hinders the functions of the 

20 master scheduler 20 and/or the &VGD system 10, as well as 
any occurrence of the failure of a task to be completed, 
or If the master scheduler 20 determines if a task is in 
jeopardy of not being completed in time. For example, 
for schedule management, alert conditions occur when a 

25 schedule expected from the schedule provider 84 is 

unavailable by a certain date, or when a received 
schedule fails to be validated. 

In schedule distribution, alert conditions arise 
when the various systems 60-82 of the master scheduler 20 

30 fail to properly communicate with each other. In 

addition, alert conditions include the occurrence of 
errors while acquiring or distributing scheduling 
information, or when a distribution, fails to start or 
complete by a certain date or time. 
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In asset management, alert conditions occur when, the 
metadata of an asset is unavailable ny a certain data as 
derived from a scheduled loading time of the 
corresponding asset, when an asset taps is not chocked in 
5 by a certain date as derived from a scheduled loading 

time of the tape, or when an. asset tape is not checked 
out by a predetermined number of days after the asset 
tape is due to be returned to the asset, storage location 
232 .. 

1.0 For content management , alerts are generated when an 

asset is either not loaded onto or not unloaded from the 
video server 11 by a certain date. Also, such content 
management alerts stay occur when an. asset is mistakenly 
unloaded or is mistakenly loaded to a wrong location, or 

IS when an incorrect asset is loaded to the video server 11. 

in addition, upon receipt of an asset metadata file, 
the video server content manager 68 may automatically 
execute a content loading procedure, which includes the 
steps of determining the availability of memory such as 

20 disk space sufficient for an entire video program, on the 

video server 11 as well as the step of determining a 
location for storing an asset, for an event on the video 
server 11. If such content cannot he accommodated, the 
event notification generator 80 generates a corresponding 

25 alert to the administrator indicating that the specific 

content may not be loaded. 

Data management alerts may be generated when the 
master scheduler application is not operational, or when 
the database 82 reaches a certain low level of capacity 

10 which may indicate insufficient resources to meet 

broadcast schedules, si nth that fewei assets axe available 
to subscribers 36 using the NVOD system 10, which may 
cause a loss of potential revenue. Alerts may also he 
generated for security management upon the detection of 



-46- 



WO 99/29108 



PC! ! S98/2S777 



repeated unauthorised attempts to. gain access to the 
master scheduler 20. 

An alert notification may cause, through the GUI 92 
at the video management, unit 90, the generation of 
5 flashing lights, colors, animation, and/or windows; a 

synthesized audio .message or warning tone; or a dialog 
box which requires acknowledgment or some response from 
the user in order to proceed. 

By setting the NOTIFY GO I option through the SU1 

10 screen 306, an administrator may be notified by such 

dialog boxes through the GUI 92- Otherwise, the 
notification may foe audio or flashing visuals as 
described above. The notification may also be sent to a 
printer or other hardcopy output devices, tor example, as 

1.5 part of the reports 96. 

FIG, 34 illustrates a GUI screen 308 for editing 
preferences and default settings, such as for automatic 
or manual tasks; that is, specified tasks may be 
performed automatically by the master scheduler 20 and/ or 

|I the video server 11, or may toe performed manually by a 

user such as an administrator with or without prompts or 
instructions generated by the task management system 72. 

FIG. 35 illustrates a GUI screen 310 for managing 
tasks such as any tasks in a selectable range of dates. 

25 Such tasks may be grouped and sorted in a scrollable 

window according to functional area, description of the 
tasks, recommended start dates, estimated duration, and 
deadline date. The current status of the task may also 
foe displayed with the actual start and end dates, and the 

30 current progress status, 

r&ont ffory^fi.yatJatn 

The event notification generator 80 generates event 
notifications, including alerts and messages to the 
administrator, either through the GUI of the 
35 administrator interface 78, through an E-mail system, or 
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t. report generator ' The evern notitieat ion 

peeifie event conditions from pollinc >i >mj rents of 
5 the master scheduler 20, Certain event: conditions ©ay be 

encountered, for example, when errors are found in 
schedule dates provided by the schedule provider 84 
during validation, or when a specific item of content is 
. . , , .<. - < , - p-ovte:3 

10 time When such event condi i oru occui the evam 

- e ( x r it ion gene} J c a jminisnrators and/oi 

other designated personnel, such as Ctoubleshooters . 

Ti i r * l < ~ oa be accessed by mul ti pi 
users simultaneously , wish authorized users such as 
15 system administrators being capable of modifying the 

operating parameters, and dura of the master .scheduler 20. . 
Remote users such as subscribers and monitoring 

scheduling data, but ass not authorised to modify the 
20 scheduling data. 

w tils the isc , p ■> < duie ; sm ar: 

method is particularly shown and described herein with 

reference to one preferred embodiments:, it is to be 

understood that various modifications in form, and detail. 
25 may be made without departing free the scope and spirit 

of the present invention. Accordingly, modifications 
r ) < r ^-a „h ^, ,u ^ heit. n but _ ] n e<. 

thereto, are to be considered within the scope of the 

present invent i on . 
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1. k master scheduler arranged to control a near- 
video-oi ismand (WQD - ' tv. r s aulas 
comprising : 

5 a ^0 - <, - t r<- syst-m inrg^d ~ 

receive and validate a schedule:- and 

=i i snt ma t r ranged to monxtca 

and control the leading of assets into a video server 
i c d io -> " t k _ >icri! - r t - 

10 include video content scheduled lor staggered 

reran cm ssi or to subscribers of the K'VOD system using a 
t lurali < v ■ > f eh a r. a > 1 s . 

2. The master scheduler of claim I further 
15 comprising : 

managen n processor including graphic user 
interface (GOT) , responsive to GUI-based commands- from an ; 
admini senator , arranged, to rnteract with the content 
manager system to control the loading of the assets.. 

20 

3 . The -master scheduler of claim .1 further 
comprising : 

a schedule distributer arranged to distribute a 
finalized schedule of programming events to externa! 
25 entities of the NVCE system, including the video server; 

c - 3u < <. r 11 

i i . t - , - s <- - - i d- ~ > , 

the validated schedule to generate the finalised schedule 
oi nrc-gran t stents 

30 

Vh mastei cheduiei f ciair> tt \t 
comprising: 

a head-end configuration manager, responsive to 
commands from an administrator, arranged to track 

11 configuration parameters of a head-end of the NVQD 
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system, wherein the configuration parameters determine 
1. The master secede ; or ■.<:" claim i , u i w: 

5 

Vi Li U x « of tasks ' be perform i ~ -ond ct th; 
loading of assets to the video server. 

10 > 1' V - -H 1 1 - T - 1 a c j l~ 

oi jpj i ■ 3 -kj r 

a notification generator, responsive to the 
occurrence of conditions a^ ct with venerated tasks 
art "it l' ■> i> i -> u _ ati - - - ~ t - 

IS 

7k; The Ttiaster scheduler 
comprising ; 

an a 1 u f ) ten 
the status and conditions., of a 

20 

< Ii t. a ter i is le r d claim ~ fu.rthet 
comprising: 

a graphic user .interface (GUIS arranged to 
jene tt n as f - ma rem it s en t Low a 

2S t u : t . V , ^ i i r eo f 

viewing a et ad data 

9. The master scheduler of claim 1 wherein the 
plurality of channels includes a test channel dedicated 
30 for testing a selected asset; and 

wherein the consent manager system includes a 
graphic use; interface to allow an administrator to view 
the selected asset, using the test channel tc verify the 
integrity or the selected asset loaded into the video 
35 server . 



of claim I further 

system arranged to monitor 
ssets in the h'VOD system. 



•tt- 



10. A nrv-vics - ^ c; a. r. : - 

to provide vices content; to a plurality of subscribers, 
the WOD system coir-prising: 

a video server arranged to store the concent it 

a memory; 

a head-er.c s - e ths c ntei 

from the video server to th« plurality of subscriber s 
over a plurality or channels : j staggered ~> t u.i i 
-of the content; 

an electronic program guide (EPS) provider 

systc 1 " 

a business support, system; 

a i • i - i , e u <p ,ic t < 

interface {GUI'! to allow an administrator to monitor and 
control the content of the video server;' and 

a master scheduler including: 

a ch s t ' c'kjv to 



for processing the validated schedule to generate a 
finalized schedule of progressing events; 

a schedule distributor arranged to 
distribute a finalized schedule of programing events to 
the video servers the SPG provider system, and the 
business support system.- and 

a content manager arranged to monitor and 
control the loading of assets into the video server 
according to the finalised schedule . 

1 se MV< yst e? f claim 1' therein h masbai 
scheduler includes; 

a head-end configuration manager, responsive to 
lianas -m. ; ! f o t_nod 
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configuration parameters of 'the head-end to determine 
NVOD channel allocations. 

12 > The JWOD system of claim .10 wherein the master 
5 scheduler includes: 

a cask management system arranged to generate 
an indication of tasks to be performed to conduct the 
loading and unloading of assets to the video server. 

10 13. The NVOD system of claim 12 wherein the master 

scheduler includes: 

a notification generator, responsive to the 
occurrence of conditions associated with generated tasks, 
arranged to notify the administrator of the conditions. 

15 

14. The NVOD system of claim .10 wherein the master 
scheduler includes: 

an asset, management system arranged to monitor 
the status and conditions of the assets.. 

20 

15. The NVOD system of claim 14 wherein the 
management processor generates an asset management screen 
on the GUI to allow ail administrator to access the asset 
management system for viewing asset-related data. 

25 

IS. The NVOD system of claim 10 wherein the 
plurality of channels includes a test channel dedicated 
to test an asset; and 

wherein the content manager generates a content 
30 management screen on the GUI to allow an administrator to 

select and view the selected asset to verify the 
integrity of the selected asset loaded into the video 
server . 
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17, A method for controlling a near -video -on- demand 
(NVOD) system,, the method comprising the steps of; 

receiving a schedule from a schedule provider; 
validating the schedule; 

processing the schedule to generate a finalised 

schedule? 

receiving assets including content; 

loading the assets into a video server 
according to the finalised schedule; 

distributing the finalized schedule to the 
video server, to a business support system, and to an 
electronic program guide system; and 

transmitting the content using staggered 
transmission over a plurality of channels to .subscribers 
of the SNOB system. 

18. The -method of claim X? wherein the step of 
receiving assets includes the step of; 

cataloging the received assets using an asset 
management system. 



19. The method of claim 17 further comprising the 
step of; 

generating a graphic user interface (GUI} 
25 screen to allow an administrator to monitor the loading 
of the assets into the video server. 



20. The method of claim 19 further comprising the 
steps csft 

30 receiving an asset selection command through 

the QUI screen to select an asset loaded into the video 
server; 

receiving a test actuation signal through the 
GUI screen ; and 
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sending the asset to a display of an 
administrator over a test channel for viewing the 
selected asset. 

21- A method for validation of scheduling 
in format t i or), comprising t 

receiving at a master scheduler said scheduling 
information from a .schedule provider ; 

receiving an asset from an asset provider; 

loading said asset into a video server; 

obtaining asset information froto said video server ; 

comparing said asset, information to said scheduling 
information; 

identifying a variance of said asset information to 
said scheduling information, 

22. The method of claim 21 wherein said step of 
comparing asset information to said scheduling 
in f or ma t i on compr i s es :. 

comparing said asset information Comprising measured 
duration information measured from said asset to said 
scheduling information comprising stored duration 
information. 

23 , The method of claim 2.1 wherein said step of 
comparing asset information to said scheduling 
information comprises; 

obtaining calculated duration information based on a 
difference between a scheduled start time and a scheduled 
end t iine ; 

comparing said asset information comprising measured 
duration information measured from said asset to said 
ca leu I a t ed dura t ion i "format ion , 
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24. The method of claim 21 wherein said seep of 
comparing asset, information to said scheduling 

In f.ormat ion comprises: 

comparing said asset information, comprising an asset 
5 return date to said scheduling information comprising a 

scheduled play date; 

said method further comprising ; 

inhibiting playing of said asset if said scheduled 
play date is later than said asset return date. 

10 

25. The method of claim 21 further comprising; 
receiving at said master scheduler program guide 

information from a program guide system.: 

comparing said program guide information to said 
15 scheduling information. 

26. The method of claim 21 further comprising; 
modifying said scheduling information at said master 

scheduler to obtain modified scheduling information? 
20 transmitting said modified scheduling information to 

a program guide system and to a business support system- 
said program guide system disseminating program guide 
information and said business support system generating 
bil ling information . 

25 

27. The method of claim 21 further comprising; 
obtaining pricing information from said asset 

provider; 

modifying said pricing information at. said master 
30 scheduler to obtain modified pricing information; 

transmitting said modified pricing information from 
said master scheduler to a .business support system, said 
business support system generating billing information. 
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